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The proposed protocol does not allow for the possible multiplexing of 
connections over links. 


Generally, this presents no problem, but it might cause loading 
restrictions in the future. Two cases where routing multiple 
connections over the same link are apparent: 


a) 


Where a user has several high speed connections, such as 
between processes that transmit files over the network. 
Assigning these connections to the same link limits the 
percentage of network resources that may be used by that 
user. This becomes particularly important when several 
store-and-forward IMP’s are used by the network to effect 
the communication. 

When two hosts each have their own independent network and 
desire to allow access to the other hosts’s network over 
the ARPA net, a shortage of links may develop. Again, the 
assignment of several connections to the same link could 
help solve the problem. 


The following changes in the protocol would make possible the future 
use of multiplexed links. It is not necessary to add the 
multiplexing, itself, to the protocol at this time. 


a) 


The END and RDY must specify relevant sockets in addition to 
the link number. Only the local socket name need be 
supplied. 

Problems arise with the RSM and SPD commands. Should they 
refer to an entire link, or just to a given connection? 
Since there is a proposal to modify the RFNM to accommodate 
these commands, it might be better to add another set of 
commands to block and unblock a connection, but I am not 
convinced that that is the best solution. 

The destintation socket must be added to the header of each 
message on the data link. Presumably this would consist of 
32 bits immediately after the header and before the marking. 
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